home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Feb 90 / MacApp.Tech$ 2⁄9⁄90 / 0624-More On UnloadAllSeg-Feb90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.2 KB  |  59 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  A33          to A34
  2.  
  3. Item    6510304                         6-Feb-90        01:03PST
  4.  
  5. From:   CDA0004                         VAR Shana Corp, Don Murphy,IVR
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    More On UnloadAllSegs
  10.  
  11. Attn: MacApp Technical
  12. SentBy: Wayne Malkin
  13. Date   2/5/90
  14. Subject    More On UnloadAllSegs
  15. From   Wayne Malkin
  16. To MacApp Technical
  17.  
  18.  Memo         Subject:More On UnloadAllSegs
  19. Hello All,
  20.  
  21. After some thought, I came to the conclusion that being able to call
  22. UnloadAllSegs from somewhere besides the main segment is amazingly useful
  23. stuff.
  24.  
  25. When opening a document, lots of stuff gets loaded including file system code,
  26. calculation parser, etc. and I once saw locked code peak at 500k. This is
  27. partly due to unfinished segmentation, but not much. Of a 750k application,
  28. I'll bet we can't get the peak code usage below 350k. This doesn't leave much
  29. for a document on a 1 meg machine.
  30.  
  31. The problem is that various parts of the document require different bits of
  32. code to load, and it adds up. It would be great to be able to unload segments
  33. after reading each part of the document. I am sure there are other places
  34. where this would be useful too, like printing, when there is slightly less
  35. memory available.
  36.  
  37. UnloadAllSegs and the subsequent LoadSeg calls would take quite a bit of time,
  38. so I would suggest a "UnloadIfLow" call which would check the locked code and
  39. call UnloadAllSegs if things look tight.
  40.  
  41. Now for the tricky parts:
  42.  
  43. If UnloadAllSegs is modified to do a stack crawl and NOT unload segments in
  44. the call chain, are we guaranteed that this will work? Does MacApp ALWAYS
  45. create corrent stack frames in its assembler bits? Does the Pascal compiler
  46. ALWAYS do the same? If not, is there some compiler options we should avoid to
  47. make sure it does? How about if C code is linked in?
  48.  
  49. Anything else wrong with the idea? Of course, to work this requires the
  50. cooperation of the application programmer. If a stack frame is forgotten in
  51. some assembler routine, the calling routine could get unloaded, at which time
  52. the memory manager may move or purge it and you end up returning into space.
  53.  
  54. Any thoughts?
  55.  
  56. -- Wayne Malkin
  57.  
  58.  
  59.